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Foreword 



This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The combination of CS and IMS services (CSI) is the parallel operation of a CS service and an IMS session between the 
same two users. It does not require a specific subscription and a specific charging correlation. 
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Scope 



The present document provides architectural details to combine CS services and IMS services for using them in parallel 
between the same two users in a peer-to-peer context. The document provides a detailed description of how capabilities 
and identities are exchanged to enable the combination of CS and IMS services between the same two UEs. 

The present document includes the following capabilities that enable the combination of CS and IMS services: 

Radio capability exchange. 

SIP based UE terminal capability exchange. 

- MSISDN number exchange in SIP. 

Establishing an IMS session in parallel to an ongoing CS call between the same two UEs. 

Establishing a CS call in parallel to an ongoing IMS session between the same two users UEs. 

Network support for establishing multimedia sessions between a UE that uses IMS origination and a UE that 
uses CSI termination. 

The individual CS call or IMS service that are combined are described in their respective specifications. 



References 



The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[3] 3GPP TS 23.081: "Line Identification supplementary services; Stage 2". 

[4] 3GPP TS 23.221: "Architectural Requirements". 

[5] 3GPP TS 23.002: "Network Architecture". 

[6] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[7] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[8] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services; Stage 2". 

[9] 3GPP TS 23.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 2". 

[10] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

[II] 3GPP TS 23.088: "Call Barring (CB) Supplementary Service; Stage 2". 

[12] 3GPP TS 23.091: "Explicit Call Transfer (ECT) Supplementary Service; Stage 2". 

[13] 3GPP TS 22.279: "Combined CS Calls and IMS Sessions; Stage 1". 
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[14] 3GPP TS 22.1 15: "Service Aspects; Charging and Billing". 

[15] 3GPP TS 23.087: "User-to-User Signalling (UUS) Supplementary Service; Stage 2". 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 2 1 .905 [ 1 ] . 

CSI session: a multimedia session that uses the CS domain to transport all or some media components (typically, voice) 
and the IMS/PS domain to transport the other media components. A CSI session can be created either by establishing 
first a CS call and subsequently a concurrent IMS session(s), or by establishing first an IMS session(s) and subsequently 
a concurrent CS call. From the user point of view, a CSI session is conceived as a single multimedia session. 

Multimedia IMS session: a multimedia session that uses only the IMS/PS domain to transport both real-time and non- 
real-time media components. 

CSI origination: the case when a UE initiates a CS call and subsequently adds an IMS session(s), or vice versa, 
addressed towards the same user. 

CSI termination: the case when a call to a UE is terminated in the CS domain (e.g. for real-time component), while an 
IMS session(s) from the same originating user and towards the same UE is terminated in the IMS/PS domain. 

IMS origination: the case when a UE initiates an IMS session(s) and the CS domain is not involved in the originating 
part of the session(s). 

IMS termination: the case when an IMS session(s) is terminated in the IMS/PS domain and the CS domain is not 
involved in the terminating part of the session(s). 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

CSI Combination of CS and IMS services 

DTM Dual Transfer Mode 

lAM Initial Address Message 

CON Connect Message 

MRFC Media Resource Function; Control part 

MRFP Media Resource Function; Physical Part 

MSRP Message Session Relay Protocol 

RAT Radio Access Technology 

RTP Real-time Transfer Protocol 



4 Overall requirements 

4.1 General description 

The "combination of CS and IMS services" (CSI) is essentially a combination of existing CS and IMS services, i.e. 
mechanisms and procedures for the IMS part of the CSI session apply according to TS 23.228 [2]. 

The UE presents the CS call and IMS session within one context to the user. To facilitate this, the following capabilities 
shall be provided: 

1 . Exchange of information related to the current radio environment; 
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2. Exchange of terminal capability information; 

3. Addition of an IMS session to an ongoing CS call; 

4. Addition of a CS call to an ongoing IMS session. 

5. Network support for establishing multimedia sessions between a UE that uses IMS origination and a UE that 
uses CSI termination. 

CSI services can be provided: 

1 . Between two CSI capable UEs that both use CSI origination and CSI termination; 

2. Between a UE that uses IMS origination and a UE that uses CSI termination. 

4.2 Service requirements 

The service requirements of combining IMS and CS services are described in TS 22.279 [13]. 



5 Architectural requirements 

5.1 Architectural requirements 

The following general requirements are applicable to CSI: 

- The solution is applicable to GERAN and UTRAN; 

A CSI capable UE requires DTM capability (in case of GERAN access) and MultiRAB capability (in case of 
UTRAN access); 

IMS networks and IMS UEs without CSI support should not be impacted; 

CS core, PS core, xRAN are not to be impacted. Conclusively, changes should be restricted to the IMS elements 
and the UEs that support CSI for IMS; 

Procedures connecting the IMS to the CS domain, to the PSTN and to other SIP networks, including other IMS 
networks should remain unchanged; 

CS only UEs and PS only UEs are not to be impacted; 

CSI capable UE provides capabilities to associate the corresponding peer-to-peer CS and IMS communication to 
present it within one context for the user. The IMS communication may be peer-to-peer session or session 
unrelated communication, e.g. IMS immediate messaging; 

The quality of the CS call (e.g. voice quality, setup delay, handover, etc.) shall not be impacted from a user 
perception point of view regardless of whether the CS call is combined with an IMS session or not; 

The use of CSI requires that the UE is CS attached, PS attached and IMS registered; 

The solution shall be transparent for the end-user; 

Existing security mechanisms for CS and IMS shall be re-used; 

For network efficiency, the UE capability exchange functionality requires the terminal to store information about 
the other terminals' capabilities; 

Functionality is required to handle remote parties who use more than one device (e.g. with the same MSISDN or 
the same public user ID). 

The same MSISDN should be used for the users IMS subscription and their CS subscription. The system 
behaviour is not specified for the case where the MSISDN for the IMS subscription and the CS subscription are 
different. 
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If the UE is not IMS registered and gets engaged in a CS call, then the UE should make an IMS registration 
using a Public User Identity causing the MSISDN used in the CS call to be implicitly registered. 

The following general requirements are applicable to multimedia sessions between UEs that use IMS origination and 
UEs that use CSI termination: 

It shall be possible to interwork between IMS origination and CSI termination for sessions that include a real- 
time (e.g. voice) components. 

NOTE: This implies the capability to perform the termination of the voice component of the session in the CS 
domain as a CS call, e.g. even if the UE for the CSI termination is not IMS registered. 

There shall be no requirement to maintain time synchronization between media transferred over different 
domains. 

The terminating CS domain and the originating IMS domain shall not to be impacted. 

The impact on UE behaviour relating to the origination and termination of IMS sessions shall be minimized. 

The impact on UE behaviour relating to the origination and termination of CS calls shall be minimized. 

5.2 Session scenarios 

The generic architectural requirements, as described in TS 23.221 [4], are applicable, and specifically 

The architectural solution shall support handover scenarios, including inter-system handover; 

The architectural solution shall support roaming scenarios with home GGSN ("IMS with GPRS roaming"); 

The architectural solution shall support roaming scenarios with visited GGSN ("IMS roaming"); 

The architectural solution shall be compatible with the IMS home control paradigm; 

The architectural solution shall consider future evolution to support interworking with conversational IMS 
services, which use PS bearers; 

The architectural solution shall consider future evolution to support migration towards conversational IMS 
services, which use PS bearers. 



5.3 UE logic 



A CSI-capable UE shall have logic to trigger the capability and identity exchange required for simultaneous 
communication on the CS and IMS domains. Further, the logic shall be able to co-ordinate current activities in the UE . 
the user preferences, whether support for simultaneous CS and PS access is available and available IMS enablers in 
such a way, that only those services/enablers are offered to a user, which can be used simultaneously. This logic shall 
function in such a way that it makes the simultaneous usage of the CS and IMS domains for the media flows as 
transparent as possible for the user. 

For the scenario of a CS call and an IMS session being established at the same time from an end user perspective, an 
IMS session can be setup first followed by adding a CS call to the IMS session using the call-flow of Section 8.4, or a 
CS call can be setup first followed by adding the IMS session to the CS call using the call-flow of Section 8.3. 



6 Architecture 

6.1 General Architecture 

The figure below shows a high level E2E architecture of a simultaneous IMS session and CS call between two end- 
users belonging to the same operator. 
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Figure 6-1 : High level architecture 

NOTE 1: No specific IMS user plane handling capabilities that are required to support CSI have been identified, i.e. 
regular IMS user plane handling applies. 

- UE 

The UE needs to support simultaneous CS and PS domain access i.e. GERAN DTM and/or UTRAN multiRAB 
capabilities. Additionally, the UE should support the capability exchange mechanism outlined in Section 7, and 
the capability to present the CS call and IMS session within the same context to the user. 

- xRAN 

The Radio Access Network is not impacted by Combinational Services. However, for CSI to function, for 
GERAN access DTM is required, for UTRAN multiRAB is required 

- PS Core 

The Packet Switched Core network remains unchanged. 

NOTE 2: For CSI to function, the PS core needs to support IMS. 

- CS Core 

The CS Core Network remains unchanged. The CS core network contains MSC/VLR, HLR, and possibly other 
logical elements according to the 3GPP specifications TS 23.002 [5], TS 24.008 [6] and TS 29.002 [7]. However 
for the Current Radio Environment information exchange to work, support for User-User Signalling Service 1 is 
required (TS 22.087 [x]). 

- IMS Core 

The IMS routes the SIP signalling between the UE (A) and UE (B). In addition, the IMS provides the session 
control and supports UE capability exchange mechanism for the support of CSI. The IMS core includes the HSS, 
the CSCFs, and other logical elements like MRFC, MRFP, MGCF, or Messaging AS, according to 3GPP 

specifications TS 23.228 [2]. 

- AS 

The means of using an AS is identical to its usage in IMS. The AS may be utilised to handle the control of the 
IMS specific aspects of a CSI session, for example service-based charging, as described in TS 22.115 [14]. If 
service-based charging mechanisms like charging based on the content of a multimedia message, the message 
type or the number of sent and/or received messages are required, then the AS should be involved. The AS may 
also provide support for time- and/or volume based charging, see TS 23.228 [2] for a more detailed description. 
For meeting the requirements of interworking between UEs that use IMS origination and UEs that use CSI 
termination, the AS will implement the role of a CSI AS as specified in clause 6.2. 



£75/ 



3GPP TS 23.279 version 9.0.0 Release 9 1 1 ETSI TS 1 23 279 V9.0.0 (201 0-01 ) 

6.2 CSI Application Server (CSI AS) 

6.2.1 CSI AS functionality 

The CSI AS is an optional application server functionality in the IMS terminating network that serves as a control entity 
for enabling multimedia sessions between UEs that use IMS origination and UEs that use CSI termination. This 
functionality can be co-hosted within a standalone or any existing application servers. The main functionality of the CSI 

AS is: 

to retrieve the CSI related capabilities of UEs which have CSI capability, via third-party registration when the 
UE registers to IMS; 

to control the CSI termination by implementing a third-party call control logic (as per 3GPP TS 23.228 [2], 
clause 4.2.4); 

to perform termination logic, i.e. examine the media components of a multimedia IMS session targeted toward a 
CSI capable UE and make a decision how to terminate them; 

to map a SIP URI to an associated Tel URI, in case the CSI AS decides to terminate an IMS session or part of 
the IMS session to the CS domain, and the CSI AS received a SIP URI of the called CSI capable user; 

to decide whether to keep itself in the session path or not; 

to handle session separation/forwarding for session initiation request, session modification request and session 
termination request. 

for CSI termination, to generate CSI capability information on behalf of the originating IMS UE and send it to 
the terminating CSI UE. 

Some of the factors that could influence the handling of session termination are: 

SIP Caller preferences. Communication Service Identifiers or lack thereof; 

SDP Media components; 

- UE capabihties. 

6.2.2 Initial Filter Criteria 

Initial filter criteria may be installed on a user's service profile regardless of their subscription so that applicable SIP 
requests are forwarded to the CSI AS in the terminating IMS network, and IMS registrations from a CSI capable UE are 
forwarded as third-party registrations to the CSI AS. 

Trigger Points in the initial filter criteria may use the following criteria: 

IMS Communication Service ID, or lack of IMS Communication Service ID; 

The UE capability of CS voice and/or video capability during IMS registrations. 

NOTE: CSI AS can dynamically activate/deactivate the service indication data in HSS according to information 
collected, e.g. UE's CSI capability information. 



7 Capability exchange 

7.1 General 

It is highly advantageous if the set of services that can be supported between two endpoints is known to the endpoints 
when (or shortly after) communication is established. This information can be used to provide an indication to the user 
of the services that are available for a particular user-to-user communication session. This can encourage use of 
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available services and avoid invocation of unavailable services, thereby avoiding customer dissatisfaction and 
unnecessary resource and bearer establishment attempts. 

Two types of capability information are described: information about the current radio environment, and UE capability 
information. 

During the radio capability exchange procedure, if the UE find that the remote UE and its current radio environment 
supports simultaneous CS and PS services and the IM Status indicates that an IMS communication is likely to be 
successful, then the UE should attempt an IMS registration (in case IMS registration had not previously been 
performed) based on preconfigured user's preference. 

7.2 Capability information 

7.2.1 Information about the current radio environment 

The purpose of the information about the current radio environment is to use it as input to the UE's and/or the user's 
decision whether to initiate further procedures (e.g. whether to start UE capability exchange, or an IMS session, or "in 
call MMS", etc.). 

This radio environment information exchange occurs over the CS domain during CS call set-up. 

This radio environment information is only valid during the lifetime of the CS call. At the end of the CS call, the UE 
should not store the radio environment information. This information can be used while the CS call is on going to help 
decide how to present service options to the user and/or whether to initiate a UE capability information exchange. 

The following information is exchanged: 

a) The terminal is capable of simultaneous CS and PS services and initiated/received the CS call in a radio 
environment that currently supports simultaneous CS and PS services. 

b) The IM Status. 

c) UE capability version, which is used for identifying current capabilities of a terminal (to notify capability 
update). 

d) Personal ME Identifier (as defined in subclause 7.4). 

The information flows for exchanging this information are shown in subclause 8.1. 

For the CSI termination, the MGCP may interwork the UUSl element between the IMS and the CS domain. 

7.2.2 UE capability information 

The UE capability information provides input to determine the set of services that can be successfully invoked between 

two users. 

NOTE 1 : This UE capability information is exchanged only over the IMS domain. The exchange of such 
capabilities may occur during peer-to-peer session or session unrelated communication. 

It shall be possible to exchange the UE capabilities described below in this subclause. Note that the exchange of these 
capabilities is subject to the availability of the information and privacy control. 

IMS Media types which can be supported as IMS media streams (i.e. media component definitions of IMS 

sessions). 

Media format parameters for supported IMS media types (Codecs, media file formats etc.). 
MSISDN and preferred SIP URI for the UE sending the UE capability information. 
Personal ME Identifier to identify which of the user's MEs the UE capability information is related to. 
UE capability version. 
Additionally, it shall be possible for the UE to use IMS to exchange capability information about: 
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CS video telephony capability; 

CS voice capability; 

Support for other IMS based capabilities or services e.g. PoC. 

The UE capability information is exchanged between the calling party and the called party. 

NOTE 2: due to varying radio environments (e.g. DTM/non-DTM, etc.) a UE capability exchange has the best 
success rate when performed outside of any other service, i.e. when no other CS/PS/IMS service is 
currently invoked. 

The information flows for exchanging UE capabilities are shown in subclause 8.2. 

7.2.3 IM Status 

The IM Status provided by the sending UE as part of the current radio environment information can be used by the 
receiving UE as an input for IMS registration, session initiation and any subsequent attempt to perform UE capability 
exchange via OPTIONS. 

NOTE: The IM Status includes the aspect that a UE may always register if the remote UE is in a state where IMS 
communication is possible. 

The IM Status provided by a UE during CS all setup is valid for the duration of that CS call. 

7.3 Registering UE capability information 

During IMS registration, a UE may register its capability information using SIP User Agent capability registration 
mechanism specified in RFC 3840 and endorsed by TS 23.228 [2]. To facilitate the operation of CSI, it shall be possible 
for the UE to register at least the following UE capabilities: 

CS video telephony capability; 

CS voice capability. 

Registration of these UE capabilities could help the core IMS network in routing SIP messages to appropriate UE when 
the caller indicates preference for these capabilities in the a SIP message using mechanism specified in RFC 3841 and 
endorsed by TS 23.228 [2]. 

The UE may update registered capabilities as specified in TS 23.228 [2]. 



7.4 IVIultiple IVIEs per user 



For network efficiency, the capability detection functionality requires the terminal to store information about the other 
terminals' capabilities. 

In order to cater for remote parties who use more than one ME (e.g. with the same MSISDN or the same public user 
ID), CSI needs a mechanism that allows for identifying a particular user's ME. This mechanism shall be capable of 
identifying a ME upon UE capability exchange, CS call setup and IMS session initiation. This enables the remote party 
to retrieve the correct stored ME capabilities. 

In order to limit network signalling (e.g. use of SIP OPTIONS to trigger other party's request) and avoid an 
inconsistency between the actual and stored capabilities, it is necessary to exchange the UE capability version. 

Procedures are needed to avoid MEs of one user having the same Personal ME Identifier. 

The Personal ME Identifier and UE capability version shall fulfil the following requirements: 

Minimal impact on SIP signalling and no impact on the IM CN subsystem; 

The identifier and the capability version should fit into UUS-1 signalling, also allowing for other services to be 
run over UUS-1; 
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The Personal ME Identifier uniquely identifies an ME of the user. 

The capability version is updated when UE changes its capability (e.g. UE performing online upgrade or 
configuration change). The capability version is unique for a given set of capabilities of a UE. 



8 



Information flows 



8.1 Exchange of capability information at CS call setup 

It shall be possible for the UE to perform end-to-end information exchange about the current radio environment during 
CS call setup. The current radio environment information exchange procedure shall include the information as outlined 
in subclause 7.2.1. 

NOTE: There will exist UEs, which do not support the radio environment exchange procedure, but do support 
parallel CS calls and IMS sessions, e.g. Rel-5 IMS-capable UMTS UEs. Thus lack of an answer in the 
radio capability exchange procedure does not mean that the remote UE cannot handle a parallel IMS 
session or the SIP based capability exchange. 

The sequence diagram in figure 8-1 outlines the exchange of information about the current radio environment, at CS 
call setup. The diagram the messages that should be used to transport the information of the current radio environment: 
the full message sequences for UUS-1 are specified in TS 23.087 [15]. For this procedure to be successful, the network 
must handle the radio capability information transparently. 
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Figure 8-1 : Exchange of current radio environment information "at" CS call setup 

1) The UE-A initiates a CS call by sending a SETUP message towards UE-B, including the current radio 
environment information encoded in the User-User Signalling IE. 

2) The CS domain of the originating network sends an lAM message including the current radio environment 
information of UE-A to the CS domain of the terminating network. Whether the MSC performs the procedures 
for UUS-1 (refer to TS 23.087 [15]), or, whether the MSC merely copies the User-User Signalling IE from the 
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SETUP message into the lAM is implementation dependent. Additional MSC based policing of the UUS 
information content is also implementation dependent. 

3) The CS domain of the terminating network sends a SETUP message lAM including the current radio 
environment information of UE-A to the UE-B. Whether the GMSC and/or the VMSC performs the procedures 
for UUS-1, or, whether they merely copy the information into the User-User Signalling IE of the SETUP 
message from the JAM is implementation dependent. 

4) The UE-B stores the current radio environment information of UE-A and sends the current radio environment 
information of UE-B in the final response to the SETUP message, i.e. the CONNECT message. UE-B takes the 
current radio environment information of UE-A into account when deciding what service options to present to 
the user and/or whether to initiate a UE capability information exchange, see subclause 8.2. 

If UE-B find that UE-A and UE-A's current radio environment supports simultaneous CS and PS services and 
the IM Status indicates that an IMS communication is likely to be successful, then UE-B should attempt an IMS 
registration (in case IMS registration had not previously been performed) based on preconfigured user's 
preference. 

NOTE: The radio environment information is only sent in the CONNECT message to avoid sending non-relevant 
information to the originating side, e.g. in case Call Forwarding on No Reply is active. 

5) The CS domain of the terminating network sends an ANM or CON message including the current radio 
environment information of UE-B to the CS domain of the originating network. 

6) The CS domain of the originating network sends a CONNECT message including the current radio environment 
information of UE-B to the UE-A. 

7) The UE-A takes the current radio environment information of UE-B received into account when deciding what 
service options to present to the user and/or whether to initiate a UE capability information exchange, see sub- 
clause 8.2. 

If UE-A find that UE-B and UE-B's current radio environment supports simultaneous CS and PS services and 
the IM Status indicates that an IMS communication is likely to be successful, then UE-A should attempt an IMS 
registration (in case IMS registration had not previously been performed) based on preconfigured user's 
preference. 

8.2 Exchange of UE capability information 

This Section outlines the exchange of UE related capability information using the SIP OPTIONS procedure to minimize 
the amount of network signalling and resource usage as well as the number of failed SIP INVITE requests. It also 
allows an up-to-date indication to the user which capabilities he could add to the ongoing call. Note that UE capability 
information exchange at IMS session initiation is specified in subclause 8.4. 

It shall be possible for a UE to request the SIP OPTIONS request to be sent to any other registered UE. In case of 
existing IMS session between UE-A and UE-B, to guarantee that SIP OPTIONS request is routed to UE-B, the SIP 
OPTIONS request should be sent as part of the existing IMS session. In case there is an ongoing CS call between UE-A 
and UE-B, it should be possible to provide a higher probability that the UE capability exchange is routed to the UE-B. 

As the SIP OPTIONS request include both the IMS Public User Identity in the form of an SIP URI and the MSISDN 
the procedure enables both UE-A and UE-B to correlate the IMS session with the CS call and within one context inform 
the user what capabilities the user is able to use. 

NOTE: If the UICC is not provisioned with the MSISDN the UE may get it during the IMS registration as an 
associated identity. 

The execution of this SIP OPTIONS request procedure is recommended when UE-A has not stored capability 
information for UE-B, or when UE-A has become aware that UE-B has changed its capabilities by comparing the stored 
and received UE capability version. 

A SIP OPTIONS may also be sent by UE-A to UE-B in case UE-A's capabilities have been updated. This request 
triggers UE-B to initiate SIP OPTIONS request towards UE-A to retrieve the updated capabilities. 
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Figure 8-2: Exchange of UE capability information 

1) UE-A sends an SIP OPTIONS request towards UE-B preferably using a SIP URI of UE-B, or a TEL URI, if no 
valid SIP URI is available. In case of an existing IMS session, the OPTIONS request should be sent as part of the 
existing session. Subject to privacy controls, in UE-A the SIP OPTIONS request shall contain MSISDN of UE- 
A, if available. 

2) The IMS Core (A) performs the normal security procedures and forwards the SIP OPTIONS request towards 
IMS Core (B). If the destination address is in the format of a TEL URI, IMS Core (A) performs MSISDN to SIP 
URI translation as per subclause 4.3.5 in TS 23.228 [2], before forwarding the SIP OPTIONS request to IMS 
Core (B). 

The IMS Core (A) should add the MSISDN of UE-A to the SIP OPTIONS request, if not included by UE-A. 

3) If the SIP OPTIONS request is not sent as part of an existing dialog, the IMS Core (B) makes a routing decision 
based on information in the caller preferences, as defined in RFC 3841, in the SIP OPTIONS request and any 
registered caller capabilities, as defined in RFC 3840, (e.g. CS-Voice or CS-Video). 

4) The IMS Core (B) then forwards the SIP OPTIONS request to UE-B. If privacy is requested, IMS Core (B) shall 
remove the MSISDN of UE-A. 

5) The UE-B stores the address information of UE-A. 

6) The UE-B sends a 200 OK that, subject to UE-B's privacy settings contain the information outlined in subclause 

7.2.2. 

7) The IMS Core (B) forwards the 200 OK to IMS Core (A). 

The IMS Core (B) should add the MSISDN of UE-B to the 200 OK, if not included by UE-B. 

8) The IMS Core (A) forwards the 200 OK to UEA-A. If privacy is requested, IMS Core (A) shall remove the 
MSISDN of UE-B. 

9) The UE-A stores or updates the UE capability information received and if not already available stores the 
address information of UE-B. 

For the capability exchange procedure to work properly UE-B should send an SIP OPTIONS request towards UE-A, in 
the following situations, provided that the associated conditions are met: 

1 . An SIP INVITE request is received from UE-A, and 
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The SIP INVITE request received from UE-A did not include any UE's capabilities capability information, 
and 

UE-B has not stored capability information for UE-A's capabilities, or UE-B's capabilities have been 
updated e.g. UE-B has been upgraded with video capability or supports a new service, or; 

The UE capability version included in the SIP INVITE request received from UE-A is different from the 
previously stored UE-A's capability version. 

2. UE-B is in a CS call with UE-A, and 

UE-B has not stored capability information for UE-A or has received a UE capability version different from 
previously stored UE-A's capability version from UE-A during CS call setup, and 

If received, the current radio environment information indicates that UE-A is capable of supporting CS and 
PS simultaneously. 

3. A SIP OPTIONS request is received from UE-A, and 

There is no ongoing (or recently finished) UE-B initiated capability exchange with UE-A. 

NOTE: The received SIP OPTIONS is not a result of a recent UE-B capability version sent from UE-B. 

In the situations 1 and 2 above, a SIP OPTIONS request may also be sent by UE-B to UE-A in case UE-B's capabilities 
have been updated. This request triggers UE-A to initiate SIP OPTIONS request towards UE-B to retrieve the updated 
capabilities. 

8.3 User adds an IMS service to an ongoing CS call 

8.3.1 IMS session set up without media requiring resource reservation 

The following sequence diagram shows an IMS service being added to an ongoing CS call when the CSI capabilities of 
UE-B have not previously been stored by UE-A and are therefore exchanged after CS call setup. 

NOTE 1: The SIP session may setup any service based on IMS and normal requirements as per TS 23.228 [2] 
apply. 
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Figure 8.3-1 : User adds an IMS session to an ongoing CS call 

1) A CS call is setup as per subclause 8.1. 

2) The UE-A should initiate an IMS capability exchange as described in section 8.2. 

NOTE 2: This step is only needed when UE-A does not have the UE-B IMS capabilities stored and vice versa. 
NOTE 3: The IMS Capability exchange will also include the correlation between the MSISDN and the SIP URL 

3) The UE-A shall send the SIP INVITE request to the IMS Core along the signalling path established during 
registration. 

4) The IMS Core (A) forwards the INVITE request to IMS Core (B). 

5) The IMS Core (B) forwards the INVITE request to UE-B. 

6) The UE-B shall associate the INVITE request with the ongoing CS call by using the MSISDN and SIP URI, 
obtained through the IMS Capability exchange procedure and/or included in the INVITE request 

7) The UE-B invokes the correct application, which associates the SIP session with the ongoing call by matching 
the identities used in the CS call and the SIP session. The UE-B then sends a 200 OK. 

8) The IMS Core (B) forwards the 200 OK to IMS Core (A). 

9) The IMS Core (A) forwards the 200 OK to UE-A. 

10) The UE-A acknowledges the 200 OK. 

1 l)The IMS Core (A) forwards the acknowledgement to IMS Core (B). 
12) The IMS Core (B) forwards the acknowledgement to UE-B. 
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13)Media as per the session setup is sent between the two UEs. 

8.3.2 IMS session set- up with media requiring resource reservation 

For an IMS session setup in the context of CSI it shall be possible to require media resource reservation as per 
procedures in TS 23.228 [2], illustrated in the use case below. 

The following sequence diagram shows an IMS service being added to an ongoing CS call when the CSI capabilities of 
UE-B have not previously been stored by UE-A and are therefore exchanged after CS call setup. Only media resource 
reservation based on the "inactive" mechanism is shown. 
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Figure 8.3-2: User adds an IMS session to an ongoing CS call 

1) A CS call is setup as per subclause 8.1. 

2) The UE-A should initiate an IMS capability exchange as described in section 8.2. If UE-B does not receive any 
IMS capability exchange from UE-A within a certain time limit the UE-B should initiate the IMS capability 
exchange, if required. 

NOTE 1 : This step is only needed when UE-A does not have the UE-B IMS capabilities stored and vice versa. 
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NOTE 2: The IMS Capability exchange will also include the correlation between the MSISDN and the SIP URL 

3) The UE-A shall send the SIP INVITE request with the media components marked "inactive" to the IMS Core 
along the signalling path established during registration. 

4) The IMS Core (A) forwards the INVITE request to IMS Core (B). 

5) The IMS Core (B) forwards the INVITE request to UE-B. 

6) The UE-B shall associate the INVITE request with the ongoing CS call by using the MSISDN and SIP URI, 
obtained through the IMS Capability exchange procedure and/or included in the INVITE request. If required, 
UE-B immediately initiates IP-CAN bearer setup. No alerting of user B needs to be carried out. 

7) The UE-B directly sends a 200 OK with the media components marked 'inactive'. 

8) The IMS Core (B) forwards the 200 OK to IMS Core (A). 

9) The IMS Core (A) forwards the 200 OK to UE-A. 

10) The UE-A initiates IP-CAN bearer setup for the media and acknowledges the 200 OK. 
1 l)The IMS Core (A) forwards the acknowledgement to IMS Core (B). 

12) The IMS Core (B) forwards the acknowledgement to UE-B. 

13) The UE-A shall send the SIP INVITE request with the media components marked "active" to the IMS core 
when the IP -CAN bearer is established on UE-A access. 

14) The IMS Core (A) forwards the INVITE request to IMS Core (B). 

15) The IMS Core (B) forwards the INVITE request to UE-B. 

16) The UE-B shall perform necessary service action to receive/send user plane media. 

17) The UE-B shall send 200 OK with the media components marked 'active' when the IP-CAN bearer is setup and 
the UE is ready to receive media. 

18) The IMS Core (B) forwards the 200 OK to IMS Core (A). 

19) The IMS Core (A) forwards the 200 OK to UE-A. 

20) The UE-A acknowledges the 200 OK. 

21)The IMS Core (A) forwards the acknowledgement to IMS Core (B). 
22) The IMS Core (B) forwards the acknowledgement to UE-B. 
23) User plane connection is established. 
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8.4 User adds a CS call to an ongoing IMS session 
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Figure 8.4-1 : User adds a CS call to an ongoing IMS Session 

1) The UE-A sends the SIP INVITE request to the IMS Core (A) using the address obtained during registration. 

The SIP INVITE may contain CSI specific information including MSISDN and current CSI capabilities in 
addition to the standard information for the desired IMS service. 

2) The IMS-Core (A) forwards the SIP INVITE request to the IMS Core (B) 

3) The IMS-Core (B) forwards the SIP INVITE request to UE-B. 

4) The UE-B should send a provisional response i.e. 18x (or a final response) and include the MSISDN of UE-B. If 
the session includes media requiring resource reservation then same principles apply as described in subclause 
8.3.2, except that the UE-B should reply with a provisional response to allow the user to answer from other UEs. 

5) The IMS Core (B) forwards the provisional or final response to IMS Core (A). 

6) The IMS Core (A) forwards the provisional or final response to UE-A 

7) The IMS flow continues as standard. 

8) The UE-A initiates a CS call by sending a SETUP message towards UE-B. 

9) The CS domain of the originating network sends an lAM message to the CS domain of the terminating network. 
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10) The CS domain of the terminating network sends a SETUP message lAM of UE-A to the UE-B. 

UE-B recognises the calling party number as negotiated in SIP session setup. 

NOTE: Without exchanging radio capabilities in IMS, the PS connection could be suspended. From the user 
experience perspective this is considered as acceptable. 

1 l)The UE-B sends ALERTING message to UE-A. 

12) The CS domain of the terminating network sends an ACM message to the CS domain of the originating network. 

13) The CS domain of the originating network sends an ALERTING message to the UE-A. 

14) The UE-B sends CONNECT message to UE-A. 

15)The CS domain of the terminating network sends an ANM message to the CS domain of the originating network. 
16) The CS domain of the originating network sends an CONNECT message to the UE-A. 

8.5 Release of CSI 

The UE shall release the CS call and the IMS session independently of each other. 

8.6 Terminating a IVIultimedia IIVIS session to a CSI UE 

Figure 8.6-1 describes the call flow for a multimedia session (e.g. with both voice and messaging components of IMS 
origination and CSI termination. The assumption is that UE 1 is both CS attached and IMS domain registered. Also, the 
MSRP protocol is used for transporting the messaging component. Note that the procedure below is simplified for 
clarity, e.g. some entities are omitted, but the normal IMS procedure for IMS/CS interworking procedure shall be 
applied. 
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Figure 8.6-1 : Call flow for terminating a multimedia IMS session to a CSI UE 

The procedure is as follows: 

1 . UE 2 initiates the multimedia session for voice and MSRP by sending an INVITE message towards UE 1 . 

2. The S-CSCF 2 of the originating network sends the INVITE message for the voice and MSRP to the S-CSCFl 
of the terminating network. 

3. Triggered by the applicable iFC, the S-CSCFl of terminating network sends the INVITE message for the voice 
and MSRP to the CSI AS. 
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4. The CSI AS invokes the Termination Logic (see clause 6.2) that decides to spHt the original IMS session into 
two sessions: One with the voice media component that will be terminated via the CS domain 1 of the 
terminating network and another with the messaging component that will be terminated via the PS domain. The 
CSI AS acts as a 3rd party call control entity for initiating and controlling these two sessions. 

5. The CSI AS initiates the first session with the voice component by sending an INVITE message to S-CSCF 1 
containing a Tel URI corresponding to UE 1 and any additional information to terminate the session in the CS 
domain. 

6-8. and 11-14. Normal IMS/CS interworking functionality is invoked and a CS voice call is established toward UE 
1 via CS domain 1 of the terminating network. 

9. The CSI AS initiates the second session with the messaging component by sending an INVITE message to S- 
CSCF 1 containing a SIP URI corresponding to UE 1. CSI AS uses any information available to ensure to send 
the second session to the same terminating UE as the destination of the voice call. 

10. and 15-16. UE 1 accepts the messaging session by sending a 200 OK message to CSI AS. 

17-19. The CSI AS accepts the original INVITE message from UE 2 by sending to UE 2 a 200 OK response. 
20. Finally, the CS voice bearer, the PS VoIP bearer, and the PS MSRP bearer are created. 
NOTE: The MSRP media could go through the CSI AS. 



9 Interaction with supplementary services 

9.1 General 

CS supplementary services apply to the CS component of the CSI call only. The present clause describes how best to 
configure and utilize CS Supplementary Services in the context of CSI. 

NOTE: The CS supplementary services are defined in TS 23.081 [3] (Line Identification), TS 23.082 [8] (Call 
Forwarding), TS 23.083 [9] (Call Waiting and Hold), TS 23.088 [11] (Barring) and TS 23.091 [12] 
(Explicit Call Transfer). 

This TS covers only the Supplementary Services that are identified as having an impact on CSI within the current 
release as stated in TS 22.279 [13]. 

9.2 Line Identification 

9.2.1 Calling Line Identity Presentation (CLIP) 

It is beneficial to utilize CLIP in the context of CSI. 

1) The called party uses the CLI of the calling party to correlate an incoming SIP INVITE with the CS call. 

2) When the called party wishes to establish an IMS session with the calling party in the context of the CS call, the 
called party uses the CLI of the calling party to derive the destination URI of the IMS session. The UE may use 
the CLI as TEL URL or may use the CLI to derive a SIP URI. 

9.2.2 Calling Line Identification Restriction (CLIR) 

If the calling party is subscribed to the automatic suppression of the presentation of her CLI, then it must be anticipated 
that the network must also automatically suppress her "IMS CLI", and, that her UE shall not reveal her CLI to other 
parties without her explicit permission. This can be achieved by either: 

a) The network operator refuses to give an IMS subscription to her. 

b) Appropriate mechanism for the HSS to control the removal of "CLI" based on subscription information. 
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NOTE: Point B is related to an IETF privacy mechanism and is identified as a generic IMS issue, not one 

specifically related to CSI. As this causes subscriber information to be sent around more than usual, it will 
be worked on as a generic IMS issue within 3GPP. 

The calling party may also wish to use CLIR on a "per call" basis. In this case, the UE shall not include any CLI 
information in any OPTIONS data exchange linked to the CS call. 

There are several mechanisms that can be imagined for the UEs to swap static terminal information as a background 
task, e.g., outside of CS calls and 'user initiated' IMS sessions. Because the E.164/identity information may need to be 
restricted from transmission to certain destinations, the UE shall ensure that the user's permission is obtained before 
such sensitive information is transmitted. 

Given that CLIP is highly desirable and useful for CSI, it is accepted that the use of CLIR causes significant 
degradation to the overall user experience in case of CSI. 

9.2.3 Connected Line Identification Presentation (COLP) 

It is beneficial to utilize COLP in the context of CSI: 

1) The calling party uses the COL of the connected party to correlate an incoming SIP INVITE with the CS call. 

2) When the calling party wishes to establish an IMS session with the connected party, the calling party uses the 
COL of the called party as the destination URI of the IMS session. The UE may use the COL as TEL URL or 
may use the COL to derive a SIP URI. 

NOTE: The availability of the COL may be affected by Call Forwarding GSM supplementary service, regulations 
and network services such as IN. 

9.2.4 Connected Line Identification Restriction (COLR) 

If the presentation of her COL is suppressed by means of a subscription or on a per call basis, then automatic 
combination of the IMS session and the CS call is unavailable. Note that user can still manually combine the CS call 
and the IMS session. 



9.3 Call Forwarding 



When a call is subject to CS call forwarding, the calling party is notified that the call has been forwarded. In CS first 
scenario, when the user would like to establish an IMS session that is to be automatically combined with this call then 
the user initiates the IMS session to the forwarded-to user. In IMS first scenario, if the UE can not associate the Public 
User Identity of the remote UE (of the IMS session) with the COL of the CS connected party, the UE realizes that the 
CS call can't be established in context of the existing IMS session and appropriately notifies the user. 

Call forwarding may result in the restriction of the presentation of the COL, depending on subscriber option settings. 
Refer to the section on Line Identification for the usage of the CLI and COL for establishing an IMS session associated 
with the CS call and for correlating an incoming IMS session with the CS call. 

For CSI termination scenario, if CSI AS gets the information that the CS call is forwarded, (e.g. MGCF gets this 
information from the COL number in CS Connect message and sends it to CSI AS), or CSI AS gets the information that 
the IMS session is forwarded/will be forwarded, it may decide what the further action will be based on local policy, i.e. 
keep the successfully established CS call or/and IMS session with the calling party. 

9.4 Call Offering 

9.4.1 Explicit Call Transfer (ECT) 

If a UE has an ongoing IMS session with one of two parties and invokes ECT, the end user may keep or terminate this 
IMS session when ECT is invoked. 

The two parties that have established a CS session after ECT will not have each others line identification and are 
therefore incapable of establishing a CSI call / session. 
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If the IMS session is established prior to the establishment of the CS call/session, then the two parties will not have each 
others line identification and are therefore incapable of establishing a CSI call/session. 

9.5 Call Completion 

9.5.1 Call Waiting (CW) and Call Hold (CH) 

When a subscriber (calling or called) is engaged in a CS call and a second call is offered to her (Call Waiting), an IMS 
session may be ongoing between that subscriber and her speech partner of the ongoing call. The offering of the second 
call (i.e. the alerting) does not affect the ongoing IMS session. 

When a subscriber (calling or called) receives a CS call when already engaged in another CS call, then she may act as 
follows. 

a) Reject the incoming call. This action does not affect the IMS session of the active call. 

b) Release the first CS call and answer the second CS call. The user may decide whether to keep the IMS session 
that was established in the context of the first CS call. The user may also decide to establish a new IMS session 
to be combined with the second CS call. 

c) Invoke Call Hold. The first call is placed on hold and the second call is answered. The following options apply to 
the IMS session for the first call: 

Option I: The IMS session is retained, but the sending and receiving of streaming data is suspended. 

Option II: The IMS session is retained and the sending and receiving of non real-time data continues. 

Similar principles apply to the case where A-party places an ongoing call on hold and establishes a second CS call. 

For CSI termination scenario, if the CSI AS gets the information that CS call is being held/retrieved (e.g. MGCF maps 
CS Call Hold/Call Retrieve signalling into SIP message and sends it to CSI AS), or the CSI AS gets the information that 
the non voice media is suspended/resumed, it may initiate session modification request to perform corresponding media 
modification towards the peer IMS UE. 

9.6 Call Barring 

If a CS call is barred, then IMS sessions in the context of the CS call are not applicable. 

If an IMS session is active and the user intends to establish a CS call, then Call Barring categories apply. 

For CSI termination scenario, if the CSI AS cannot establish a voice call/IMS session with the CSI capable UE, e.g. due 
to Call Barring service, it may remove the voice/non voice component by negotiating /renegotiating media with the 
calling party. 



10 Other considerations 
10.1 Handover 

- Handover from DTM GERAN or UTRAN to non-DTM GERAN 

If, during a simultaneous IMS session and CS call between two end-users, one of the end-users makes an 
intersystem handover into a non-DTM GERAN access, in this case the data traffic on the PDP contexts are 
handled as per procedures described in TS 23.060 [10]. 

- Handover from non-DTM GERAN to DTM GERAN or UTRAN 

When a UE is participating in a CS call and not able to operate in Class A mode of operation, the UE cannot 
perform IMS capability exchange procedures. When the UE is again able to operate in Class A mode of 
operation, the UE can perform the IMS capability exchange procedures during the CS call, if required according 
to procedures outlined in sections 7 and 8. 
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10.2 Relation to SMS 

A user should be able to send or receive SMS during an ongoing CSI session. SMS is in general treated independently 
from CSI. 
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Annex A (Informative): 

Support of CSI origination towards IIVIS termination with CSI 

interworking 

A.1 Introduction 

This annex describes the flows and architecture for CSI originations towards IMS termination with CSI interworking. 

CSI interworking is the ability to perform the interworking between e.g. a pure IMS voice/video session and a 
combination of a CS call and an IMS session. 

A.2 Overview 

CSI interworking from CSI origination to IMS termination is required to enable communication from UE's support CSI 
towards UEs supporting IMS termination. CSI interworking can be implemented in two different ways: 

1) CSI interworking can also be achieved in the terminating terminal if the operator has control of the terminal. 
This is beyond the scope of this document. 

2) CSI Interworking is detected and performed in the originating network. 

3) CSI Interworking is detected and performed in the terminating network. 



A. 3 Procedures 

A.3.1 General Architecture 

Figures A. 1 and A.2 show an architecture for the general architecture for CSI interworking when CSI origination and 
IMS termination is used for the CSI interworking with the support of interworking in the network. Figure A. 1 shows the 
case where the CSI interworking is performed in the originating network, and figure A.2 shows the case where the CSI 
interworking is performed in the terminating network. 
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CSI Origination 
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domain 
2 



xRAN 
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IMS 



ilVIS termination 

Multimedia IMS session (for voice and other) 
CS call (for voice) 
IMS session (for other) 



NOTE: When to support interworl<ing in the originating networl< is a matter of policy in the home operator 
originating network. Such policy could take into account the destination network. 

Figure A.1 : General architecture and signalling flow in case of CSI origination and IMS termination 

with CSI interworking in originating network 



CS 



UE1 



xRAN 



IMS 




CSI Origination 



IMS termination 



Multimedia IMS session (for voice and other) 
CS call (for voice) 
IMS session (for other) 



Figure A.2: General architecture and signalling flow in case of CSI origination and IMS termination 

with CSI level interworking in terminating network 

The solid lines present the signalling flow between UE 1 and UE 2. The voice call (yellow line) which is initiated by 
UE 1 is routed to the CSI-AS, while the IMS session for other services is also routed to the CSI-AS. The CSI-AS 
continues the communication towards UE 2 with a single session using normal IMS routing procedure. The above 
examples illustrate the interworking in both originating and the terminating networks and further consideration is 
required in order to determine whether the CSI-AS is in the originating network, terminating network or both. 

NOTE: This is for the case when the UE in CSI origination is not subscribing the VCC service. 
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A.3.3 Call flows for setting up the voice session for CSI origination 
and IIVIS termination with CSI interworking 

Figure A.3 shows the flows for establishing the voice session for CSI origination and IMS termination with the 
interworking performed in the originating network. The flow is simplified and omits elements such as I-CSCF and HSS 
from IMS Core B. 
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Figure A.3: CSI interworking on originating side for CSI origination 

NOTE: The functionality of the CAMEL Svc and CSAF are the same as described in TS 23.206: "Voice Call 
Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2". 

1. The CSI user originates a voice call in the CS domain using a CSI UE to party-B. 

2. Origination triggers at the VMSC are detected; VMSC sends an Initial DP message towards the gsmSCF. 

3. The gsmSCF invokes the CSI interworking Application's CAMEL Service that determines that the call needs to 
be interworked to IMS for CSI; thus, the CAMEL Service interworks the call to the IMS by allocating an IMRN 
and returning it to the gsmSCF; otherwise it responds with a CAP Continue. 

NOTE: How the information available to the CAMEL Service is used to decide whether the call should be routed 
through the IMS is implementation specific. 

4. The gsmSCF responds with a CAP Connect message containing the Original Called party ID and Destination 
Routing Address. Destination Routing Address contains the IMRN to route the call to the CSAF. Handling of 
Destination Routing Address and Original Called party ID is as defined in TS 23.078 [4]. 

5. The VMSC routes the call towards the user's home IMS network using the IMRN via an MGCF in the home 
network. 
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6. The MGCF initiates an INVITE towards the I-CSCF in the home IMS of the originating CSI user. The calling 
party number and/or original called number are included in the INVITE if they are received from the PSTN call 
setup signalling (e.g. IS UP). 

7. The I-CSCF routes the INVITE based on one of the following standard procedures specified in "PSI based 
Application Server termination - direct" and "PSI based Application Server termination - indirect" procedures in 
TS 23.228 [2]. 

7a. The I-CSCF forwards the INVITE to the CSAF via the S-CSCF that is assigned to the IMRN. 

7b. The I-CSCF forwards the INVITE directly to the CSAF. 

8. If, when the INVITE arrives at the CSI Interworking Application, it is processed by the CSAF of the CSI 
Interworking Application that may use the IMRN to retrieve the original called party number and the calling 
party number from the CAMEL Service. The CSAF uses the original called number and the calling party number 
to setup the outgoing call leg to party-B in accordance with the AS origination procedure defined in clause 5.6.5 
ofTS 23.228 [2]. 

9. The CSAF sends the INVITE back to the S-CSCF for completion of the call toward the remote end. 

10. The S-CSCF forwards the INVITE to the CSI-AS 

1 1. The CSI-AS forwards the INVITE to the S-CSCF. 

12. The CSI-AS forwards the INVITE to the IMS Core B. 

The rest of the call is established as per normal SIP signalling with interworking towards the CS domain. The voice call 
is considered to be established. 

Figure A.4 shows the flows for establishing the voice session for CSI origination and IMS termination with the 
interworking performed in the terminating network. The flow is simplified and omits elements such as I-CSCF and 
HSS. 
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Figure A.4: CSI interworking on terminating side for CSI origination 

1. UEl initiates a voice call on the CS side by sending a SETUP message to the CS domain (MSC). 

2. The originating network generates an lAM which is forwarded to the visiting network. The lAM is routed to a 
MGCF. 

3. The MGCF generates an INVITE and forwards the INVITE the call to S-CSCF2. 

4. S-CSCF2, based upon iFC, forwards the INVITE to CSI-AS2. 
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5. CSI-AS2 terminates the INVITE from the MGCF and generates a new INVITE towards UE2. It also performs 
the service logic required for originating CSI interworking (e.g. 3rd party call control). 

6. CSI-AS2 sends the INVITE back towards S-CSCF2. 

7. S-CSCF2 forwards the INVITE to UE2. 

8. UE2 accepts the session by responding to S-CSCF2 with a 200OK. 

9. S-CSCF2 forwards the 200 OK to CSI-AS2. 

10. CSI-AS2 forwards the 200OK back to S-CSCF2. 

11. S-CSCF2 forwards the200OK to the MGCF. 

12. The MGCF generates a CON messages which is sent to the originating CS domain. 

13. The MSC in the CS domain accepts the call by sending a CONNECT to UEl. 
The voice bearer is considered to be established. 

A.3.4 Call flows for adding IMS sessions to existing voice calls for 
CSI origination with CSI interworking 

In addition to the call flows described above, the following call flows describe some of the cases where CSI 
interworking can occur within the network on the terminating side. 

Figure A.5 below shows a call flow for adding an IMS session (e.g. MSRP session) to an existing voice call. In this case 
the voice call was established with IMS origination, and the interworking is performed in the network. The addition of 
the IMS session is from the terminal that performed the IMS origination. 

NOTE: The procedure below is simplified for clarity, e.g. some entities are omitted, but the normal IMS 
procedure for IMS/CS interworking procedure shall be applied. 
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Figure A.5: Call flow for adding IMS session to existing voice call using a the existing dialog 

1. The UE 2 initiates a request for adding the MSRP by sending the RE-INVITE message within the existing 
dialogue. 

2. The S-CSCF 2 of the originating network sends the RE-INVITE message for the MSRP to the S-CSCF 1 of the 
terminating network, in accordance with the already established sessions. 

3. The S-CSCF 1 sends the INVITE message for the MSRP to the CSI-AS 

4. The CSI-AS generates an INVITE that is targeted towards the user of UEl and sends this to S-CSCFl 
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5. The S-CSCFl sends the INVITE towards UEl 

6. The UE 1 responds to the INVITE message with the 200OK message. 

7. The S-CSCFl sends the 200OK message to the CSI-ASl. 

8. The CSI-ASl generates a 200OK and sends it to S-CSCFl. 

9. S-CSCFl sends the 200OK message to S-CSCF 2 of the originating network. 

10. The S-CSCF 2 of the originating network sends the 200OK message to the UE 2. 

1 1 . Finally, the user plane for the MSRP is created. 

NOTE: The MSRP media could go through the CSI AS. 

Figure A.6 shows a call flow for adding an IMS session (e.g. MSRP session) to an existing voice call. In this case the 
voice call was established with CSI origination, and the interworking is performed in the network. The addition of the 
IMS session is from the terminal that performed the CSI origination. 

NOTE: The procedure below is simplified for clarity, e.g. some entities are omitted, but the normal IMS 
procedure for IMS/CS interworking procedure shall be applied. 

The flow below assumes that the CSI interworking was performed in the originating network. 
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Figure A.6: Call flow for adding IMS session to existing voice call using a the existing dialog 

1. The UEl initiates a request for adding the MSRP by sending an INVITE message within the destination towards 
UE2. 

2. The S-CSCF 1 of the originating network sends the INVITE message for the MSRP to CSI- AS 1 based upon the 
filter criteria. 

3. The CSI-ASl generates a RE-INVITE message within the existing dialogue towards UE2. This is returned to 
the S-CSCFl. The RE-INVITE contains the SDP for the original media (e.g. the audio) and the added media 
(e.g. MSRP). 

4. S-CSCFl forwards the RE-INVITE message towards S-CSCF2 within the existing dialogue. 

5. S-CSCF2 forwards the RE-INVITE towards UE2. 

6. The UE 2 responds to the INVITE message with the 200OK message. 
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7. The S-CSCF12sends the 200OK message to S-CSCF2. 

8. S-CSCFl forwards the 200OK message CSI-ASl. 

9. CS-ASl generates a 200OK messages and forwards the message to S-CSCFl. 

10. S-CSCFl of the originating network sends the 200OK message to the UEl. 

1 1. Finally, the user plane for the MSRP is created. Note that the MSRP media could go through the CSl AS. 

Figure A.7 shows a call flow for adding a voice call to an existing IMS session (e.g. MSRP session). In this case the 
original IMS session was established with CSl origination, and the interworking is performed in the network. The 
addition of the IMS session is from the terminal that performed the CSl origination. 

NOTE: The procedure below is simplified for clarity, e.g. some entities are omitted, but the normal IMS 
procedure for IMS/CS interworking procedure shall be applied. 

The flow below assumes that the CSl interworking is performed in the originating network. 
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NOTE: The functionality of the CAMEL Svc and CSAF are the same as described in TS 23.206: "Voice Call 
Continuity (VCC) between Circuit Switched (CS) and IP Multimedia Subsystem (IMS); Stage 2". 

Figure A.7: Call flow for adding a voice call to an existing IMS session 

1. The CSl user originates a voice call in the CS domain using a CSl UE to party-B. 

2. Origination triggers at the VMSC are detected; VMSC sends an Initial DP message towards the gsmSCF. 

3. The gsmSCF invokes the CSl interworking Application's CAMEL Service that determines that the call needs to 
be interworked to IMS for CSl; thus, the CAMEL Service interworks the call to the IMS by allocating an IMRN 
and returning it to the gsmSCF; otherwise it responds with a CAP Continue. 
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NOTE: How the information available to the CAMEL Service is used to decide whether the call should be routed 
through the IMS is implementation specific. 

4. The gsmSCF responds with a CAP Connect message containing the Original Called party ID and Destination 
Routing Address. Destination Routing Address contains the IMRN to route the call to the CSAF. Handling of 
Destination Routing Address and Original Called party ID is as defined in TS 23.078 [4]. 

5. The VMSC routes the call towards the user's home IMS network using the IMRN via an MGCP in the home 
network. 

6. The MGCP initiates an INVITE towards the I-CSCF in the home IMS of the originating CSI user. The calling 
party number and/or original called number are included in the INVITE if they are received from the PSTN call 
setup signalling (e.g. IS UP). 

7. The I-CSCP routes the INVITE based on one of the following standard procedures specified in "PSI based 
Application Server termination - direct" and "PSI based Application Server termination - indirect" procedures in 
TS 23.228 [2]. 

7a. The I-CSCP forwards the INVITE to the CSAP via the S-CSCP that is assigned to the IMRN. 

7b. The I-CSCP forwards the INVITE directly to the CSAP. 

8. If, when the INVITE arrives at the CSI Interworking Application, it is processed by the CSAP of the CSI 
Interworking Application that may use the IMRN to retrieve the original called party number and the calling 
party number from the CAMEL Service. The CSAP uses the original called number and the calling party number 
to setup the outgoing call leg to party-B in accordance with the AS origination procedure defined in clause 5.6.5 
of TS 23.228 [2]. 

9. The CSAP sends the INVITE back to the S-CSCP for completion of the call toward the remote end. 

10. The S-CSCP forwards the INVITE to the CSI-AS. 

1 1. The CSI-AS forwards the RE-INVITE to the S-CSCP. The RE-INVITE contains the SDP for the original media 
(e.g. MSRP) and the added media (e.g. audio). 

13. The CSI-AS forwards the RE-INVITE to the IMS Core B. The CS part of the CSI session is now interworked to 
IMS Core B. 

The rest of the call is established as per normal SIP signalling with interworking towards the CS domain. The voice call 
is considered to be established. 
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